Over 1,000 Windows 95 Programs/Over 1000 Windows 95 Programs (Microforum) (Disc 1).iso/1245/readme.txt

Text File | 1997-04-18 | 6KB | 108 lines

The sample COBOL program file STOCKCON.CBL and structured programming techniques
--------------------------------------------------------------------------------

Lately, not more than two or three weeks ago, Amanda, posted a message in the
newsgroup COMP.LANG.COBOL, crying desperately for help to solve her current
problems with her program. I responded to her posting by email and I got an
email message from her containing fragments of COBOL code with lots of
errors and fragments of program specifications which did not make much sense.

So, I have decided to write a sample program, starting from incomplete
code fragments and program specification to create STOCKCON.CBL. Of course,
I had to improvise a little bit to conceptualize a problem that was not
fully explained to me. This was to give her an idea as to how one can
create a parallell between the program specification and the program
implementation by using the structured programming techniques in COBOL
language. Since the COBOL language implementation for screen handling is
highly platform-dependent, I have used the most primitive ISO/ANSI standard
screen handling statements in order to avoid compilation problems on her
specific platform. I have avoided to use the function keys of the keyboard
also. So, there is nothing pretty about data entry, data display or
menu presentations in this sample program. However, I have done my best
to illustrate the structured programming techniques that I have been using
for a long time. One can talk a lot about these techniques, but the best
thing to do is to give an example so that one can see how these techniques
are employed in real life. Thanks to the structured programming techniques
employed, it was possible, for me, to write, compile, link and test this
sample program in half a day's time. Here are the highligts of these
techniques:

1) Never use GO TO.

2) Go as deep in procedure calls as it is necessary. I have never hit the
   compiler stack limits so far. So, you will probably not hit it either.

4) Use meaningful paragraph names. Keep paragraph names as short as
   necessary but not shorter than necessary. So, if necessary, use up
   the maximum lenght of 30 characters when you need to do so.

5) Use meaningful constant/data names as long as necessary, applying the
   same criteria as those applied to paragraph names.

4) Make the COBOL source file as close to simple English language
   as possible so that, only by reading the COBOL source file, you
   can feel like you are reading the program specification in detail.

5) Use COBOL constants (78 level items) with joy when needed. This
   will render the COBOL code more understandable and it will make
   modification of your code almost free of errors. It is
   much easier to change the value of the numeric constant
   from 30 to 45 in the following example of constant declaration
   than hunting for every occurrence of the constant value 30
   in a large source file and change each one to 45.

   78 MaximumNumerOfLinesPerPage  Value 30.

6) If your editor and/or platform of development allows it, use a
   Capital letter to form Constant/Data/Paragraph names instead of
   dashes, thus gaining precious name space and still insuring
   legibility as in the example below:

   A113-DoMainProcess but not A113-DO-MAIN-PROCESS.

7) Use four digit alphanumeric paragraph prefixes. This will allow
   you to use the same paragraph name several times, when you need
   to do so in your source program, thus rendering the paragraph
   name unique. Examples:

   A251-AddDataToFile.
    A252-DisplayScreenMask.

   A452-UpdateDataFile.
    A453-DisplayScreenMask.

   Since, A252-DisplayScreenMask is called by A251-AddDataToFile,
   why bother trying to say DisplayAddDataToFileScreenMask, running out of
   name space and than force yourself to find a cryptic paragraph name.
   Since hierachical call order makes it evident that A252-DisplayScreenMask
   called by A251-AddDataToFile, it suffices to say DisplayScreenMask
   prefixed by A252. And in its context, it is also evident that, even
   if you use the same paragraph name in A453-DisplayScreenMask, it is
   the screen mask of the procedure of A452-UpdateDataFile. There are
   abondant other examples of similar situations when you code your
   program. So, quickly chose a paragraph prefix and continue with ease
   to code your program in a meaningful way in its context.

8) Use a rectangular, for comments, in front of each division, section
   and paragraph to aerate your code. Blank lines increase the legibility
   of the code when used as in the example program. You can extend the meaning
   of the paragraph name within the preceding rectangle of comments
   line or just repeat it in open seperated form as an English language
   phrase. This much extra work is tolerable and it improves the
   reading of the code if you want to have an exlusive reading session
   without glancing at the formed paragraph names.

9) Pay a lot of attention to error conditions for file input/output,
   for external routine calls, calculation statements, etc. and
   handle them gracefully when possible and let the program exit
   when an abnormal error condition occurs. When you are not sure
   if an error can be handled, exit the program with an abnormal
   end condition rather than doing nothing to handle the error
   condition.

10)Use a separate paragraph name for each fatal error and indicate
   at least its paragraph prefix when you exit the program with
   abnormal end condition. Thus, you can pinpoint exactly where
   the error has occured. If necessary, you may also add extra
   information such as file-status code, etc.